读了鸿蒙 OS 的代码后，我发现优秀项目都有这个共性！

查看原文

其他

读了鸿蒙 OS 的代码后，我发现优秀项目都有这个共性！

From: 马超程序人生 2019-10-30

作者 | 马超

责编 | 胡巍巍

出品 | 程序人生（ID：coder_life）

最近有人在Github上开源了鸿蒙OS（https://www.github.com/Awesome-HarmonyOS）并且累计获得了一万多颗Star。

从华为的官方宣传中就提到了“安卓总代码超过一亿行，其中内核代码超过2000万行，实际用到的不过8%，如此庞大和冗余的这种设计，实际上很难保证流畅度，使用效率很低。”

而笔者之前介绍过的TDengine（https://github.com/taosdata/TDengine）做为一个数据库项目更是仅用1.5M安装包就能搞定，代码效率高的惊人。

所以从这方面我们也能看出优秀的项目对于速度的要求都是极致的。

不过这两个项目开源后都引发了一些争议，比如鸿蒙开源当天就有人发微博说华为只是做了个安卓的定制版，质量甚至还不如MIUI，笔者的这位创造Github冠军项目的老男人，堪称10倍程序员本尊发布后，也有人在评论说TDengine的consumer-productor实现无法通过code review。

但是仔细阅读这些评论可以发现，这些批评其实都不是基于代码的。笔者做为一名程序员奉行“Talk is cheap,show me the code"的理念，所以我利用周末时间阅读了这两个项目的代码，发现了很多值得学习的设计亮点。

尤其是鸿蒙OS做为操作系统项目而Tdengine做为数据库项目，比较他们两者在同一模块上的设计异同，非常有收获，下面给各位读者分享一下，如有意见欢迎留言。

两个项目对于任务调度模块的实现对比

1.鸿蒙OS的调度模块

与一般操作系统一样，鸿蒙也将任务状态通常分为以下三种：

就绪（Ready）：
该任务在就绪列表中，只等待CPU。

运行（Running）：
该任务正在执行。

阻塞（Blocked）：
该任务不在就绪列表中。
包含任务被挂起、任务被延时、任务正在等待信号量、读写队列或者等待读写事件等。

任务状态迁移图

其代码位置在los_task.c，以任务恢复函数LOS_TaskResume为例，其代码如下：

LITE_OS_SEC_TEXT_INIT UINT32 LOS_TaskResume(UINT32 uwTaskID)
{
    UINTPTR uvIntSave;
    LOS_TASK_CB *pstTaskCB;
    UINT16 usTempStatus;
    UINT32 uwErrRet = OS_ERROR;

    if (uwTaskID > LOSCFG_BASE_CORE_TSK_LIMIT)
    {
        return LOS_ERRNO_TSK_ID_INVALID;
    }

    pstTaskCB = OS_TCB_FROM_TID(uwTaskID);
    uvIntSave = LOS_IntLock();
    usTempStatus = pstTaskCB->usTaskStatus;

    if (OS_TASK_STATUS_UNUSED & usTempStatus)
    {
        uwErrRet = LOS_ERRNO_TSK_NOT_CREATED;
        OS_GOTO_ERREND();
    }
    else if (!(OS_TASK_STATUS_SUSPEND & usTempStatus))
    {
        uwErrRet = LOS_ERRNO_TSK_NOT_SUSPENDED;
        OS_GOTO_ERREND();
    }
    //以上为任务状态检查
    pstTaskCB->usTaskStatus &= (~OS_TASK_STATUS_SUSPEND);//清除任务的suspend标志位置
    if (!(OS_CHECK_TASK_BLOCK & pstTaskCB->usTaskStatus) )//若任务的还自在阻塞状态则变为就绪状态 ，并调用 LOS_Schedule()进行调度
    {
        pstTaskCB->usTaskStatus |= OS_TASK_STATUS_READY;
        LOS_PriqueueEnqueue(&pstTaskCB->stPendList, pstTaskCB->usPriority);
        if (g_bTaskScheduled)
        {
            (VOID)LOS_IntRestore(uvIntSave);
            LOS_Schedule();
            return LOS_OK;
        }
        g_stLosTask.pstNewTask = LOS_DL_LIST_ENTRY(LOS_PriqueueTop(), LOS_TASK_CB, stPendList); /*lint !e413*/
    }

    (VOID)LOS_IntRestore(uvIntSave);
    return LOS_OK;

LOS_ERREND:
    (VOID)LOS_IntRestore(uvIntSave);
    return uwErrRet;
}

我们看到这个函数的处理过程基本分为三步：

任务合法性（TaskId）及任务状态校验：判断任务序号以及任务当前状态是否确实为挂起。

改变任务状态：将任务的suspend状态位清掉

起用任务调度：如果任务被阻塞，则调起LOS_Schedule进行调度。

我们知道完整的LINUX内核是支持将任务指定在某个CPU上运行的，不过鸿蒙OS做为一个微内核的移动操作系统没有继承这些复杂的功能，直接做了减法，实现一个最简模型。

2.TdEngine的任务调度模块

而对比TDengine的调度模块tsched.c，可以看到TDengine更是放弃了任务优先级调度功能，因为做为时序数据库其数据全是按照生成时间排序处理入库的，所以他的只将任务调度模块，仅实现了以下四个功能

初始化任务队列

加入任务

循环处理任务

销毁任务队列

从其循环处理任务的函数（taosProcessSchedQueue），可以看出它只是队尾不断取出任务进行循环处理，而没有优化级调整排序的过程。

void *taosProcessSchedQueue(void *param) {
  SSchedMsg    msg;
  SSchedQueue *pSched = (SSchedQueue *)param;

  while (1) {
    if (sem_wait(&pSched->fullSem) != 0) {
      pError("wait %s fullSem failed, errno:%d, reason:%s", pSched->label, errno, strerror(errno));
      if (errno == EINTR) {
        /* sem_wait is interrupted by interrupt, ignore and continue */
        continue;
      }
    }

    if (pthread_mutex_lock(&pSched->queueMutex) != 0)
      pError("lock %s queueMutex failed, reason:%s", pSched->label, strerror(errno));

    msg = pSched->queue[pSched->fullSlot];
    memset(pSched->queue + pSched->fullSlot, 0, sizeof(SSchedMsg));
    pSched->fullSlot = (pSched->fullSlot + 1) % pSched->queueSize;//从队尾取出消息不断处理

    if (pthread_mutex_unlock(&pSched->queueMutex) != 0)
      pError("unlock %s queueMutex failed, reason:%s\n", pSched->label, strerror(errno));

    if (sem_post(&pSched->emptySem) != 0)
      pError("post %s emptySem failed, reason:%s\n", pSched->label, strerror(errno));

    if (msg.fp)
      (*(msg.fp))(&msg);
    else if (msg.tfp)
      (*(msg.tfp))(msg.ahandle, msg.thandle);
  }
}

int taosScheduleTask(void *qhandle, SSchedMsg *pMsg) {
  SSchedQueue *pSched = (SSchedQueue *)qhandle;
  if (pSched == NULL) {
    pError("sched is not ready, msg:%p is dropped", pMsg);
    return 0;
  }

  if (sem_wait(&pSched->emptySem) != 0) pError("wait %s emptySem failed, reason:%s", pSched->label, strerror(errno));

  if (pthread_mutex_lock(&pSched->queueMutex) != 0)
    pError("lock %s queueMutex failed, reason:%s", pSched->label, strerror(errno));

  pSched->queue[pSched->emptySlot] = *pMsg;
  pSched->emptySlot = (pSched->emptySlot + 1) % pSched->queueSize;

  if (pthread_mutex_unlock(&pSched->queueMutex) != 0)
    pError("unlock %s queueMutex failed, reason:%s", pSched->label, strerror(errno));

  if (sem_post(&pSched->fullSem) != 0) pError("post %s fullSem failed, reason:%s", pSched->label, strerror(errno));

  return 0;
}

两个项目对于定时器（timer)的实现对比

1.鸿蒙的timer

在鸿蒙的官方文档中是这么介绍定时器的：

软件定时器，是基于系统Tick时钟中断且由软件来模拟的定时器，当经过设定的Tick时钟计数值后会触发用户定义的回调函数。定时精度与系统Tick时钟的周期有关。

硬件定时器受硬件的限制，数量上不足以满足用户的实际需求，因此为了满足用户需求，提供更多的定时器，Huawei LiteOS操作系统提供软件定时器功能。软件定时器扩展了定时器的数量，允许创建更多的定时业务。

2.运作机制

软件定时器是系统资源，在模块初始化的时候已经分配了一块连续的内存，系统支持的最大定时器个数可以在los_config.h文件中配置。

软件定时器使用了系统的一个队列和任务资源，软件定时器的触发遵循队列规则，先进先出。
定时时间短的定时器总是比定时时间长的靠近队列头，满足优先被触发的准则。

软件定时器以Tick为基本计时单位，当用户创建并启动一个软件定时器时，Huawei LiteOS会根据当前系统Tick时间及用户设置的定时间隔确定该定时器的到期Tick时间，并将该定时器控制结构挂入计时全局链表。

当Tick中断到来时，在Tick中断处理函数中扫描软件定时器的计时全局链表，看是否有定时器超时，若有则将超时的定时器记录下来。

Tick处理结束后，软件定时器任务（优先级为最高）被唤醒，在该任务中调用之前记录下来的超时定时器的处理函数。

3.代码解读

如果官方文档的说明没看懂，可以直接查阅其源代码，具体位置在los_swtmr.c

下面笔者来简述一下鸿蒙定时器的工作原理。

首先明确鸿蒙的定时器是为了节省硬件定时器资源而设计的。
由于硬件定时器往往数量有限而系统实际运行中，对于定时器的需求往往高于硬件定时器的数量，所以操作系统都会实现软件定时器以满足用户需求。

先启动硬件定时器，注册硬件定时器的tick事件，也就是硬件定时器到时发生tick时会调用软件定时器的处理函数。

将在同一时刻到期的timer放在同一链表中。

在硬件产生tick事件时，取出当时到期的定时器列表，并顺序调起链表内所有到时定时器的处理函数。

LITE_OS_SEC_TEXT VOID osSwTmrTask(VOID)
{
    SWTMR_HANDLER_ITEM_P pstSwtmrHandle = (SWTMR_HANDLER_ITEM_P)NULL;
    SWTMR_HANDLER_ITEM_S stSwtmrHandle;
    UINT32 uwRet;

    for ( ; ; )
    {
        uwRet = LOS_QueueRead(m_uwSwTmrHandlerQueue, &pstSwtmrHandle, sizeof(SWTMR_HANDLER_ITEM_P), LOS_WAIT_FOREVER);
        if (uwRet == LOS_OK)
        {
            if (pstSwtmrHandle != NULL)
            {
                stSwtmrHandle.pfnHandler = pstSwtmrHandle->pfnHandler;
                stSwtmrHandle.uwArg = pstSwtmrHandle->uwArg;
                (VOID)LOS_MemboxFree(m_aucSwTmrHandlerPool, pstSwtmrHandle);
                if (stSwtmrHandle.pfnHandler != NULL)
                {
                    stSwtmrHandle.pfnHandler(stSwtmrHandle.uwArg);
                }
            }
        }
    }//end of for
}